Validate written data

ABSTRACT

Data and a first error detection code related to the data is received. That the received data is written correctly to a memory is validated based on the first error detection code and/or a comparison of the written data to the received data. An alert is generated if it is determined that the written data is incorrect.

BACKGROUND

A controller may receive data to be written to a memory. The controllermay transmit the data to the memory and the memory may store the data,Manufacturers, vendors and/or suppliers are challenged to provide userswith more accurate methods for ensuring that data is written correctlyto the memory.

BRIEF DESCRIPTION OF THE DRAWINGS

The following detailed description references the drawings, wherein:

FIG. 1 is an example block diagram of a device to validate that data iswritten correctly to a memory;

FIG. 2 is another example block diagram of a device to validate thatdata is written correctly to a memory;

FIG. 3 is yet another example block diagram of a device to validate thatdata is written correctly to a memory;

FIG. 4 is an example block diagram of a computing device includinginstructions for validating that data written to a memory is correct;

FIG. 5 is an example flowchart of a method for validating that datawritten to a memory is correct; and

FIG. 6 is another example flowchart of a method for validating that datawritten to a memory is correct.

DETAILED DESCRIPTION

Specific details are given in the following description to provide athorough understanding of embodiments. However, it will be understoodthat embodiments may be practiced without these specific details. Forexample, systems may be shown in block diagrams in order not to obscureembodiments in unnecessary detail. In other instances, well-knownprocesses, structures and techniques may be shown without unnecessarydetail in order to avoid obscuring embodiments.

A controller, such as a memory controller, may seek to ensure that datait sends to a memory, such as a dynamic random access memory (DRAM), isreceived correctly, or else corrupted data may be written to the memory.Memory controllers and memories may communicate via a double data rate(DDR) mechanism. Some types of double data rate (DDR) mechanisms mayinclude link protection by sending an error detection code with the dataalong the link between the memory controller and the memory.

For example, in fourth generation DDR (DDR4), a memory controller maygenerate a cyclic redundancy check (CRC) for each data packet sentduring write operations to the DRAM. In turn, the DRAM may check for avalid CRC prior to storing the data. If the CRC check fails, the DRAMmay signal to the memory controller to resend the data. However, currentmechanisms do not further check if the data is still correct after beingwritten to the DRAM.

Examples may provide a mechanism to validate that data has been writtencorrectly to a memory, such as DRAM. An example device may include areceiving unit, a validation unit, and an alert unit. The receiving unitmay receive data and a first error detection code related to thereceived data. The validation unit may validate that the received datais written correctly to a memory, based on the first error detectioncode and/or a comparison of the written data to the received data. Thealert unit may generate an alert if the validation unit determines thatthe written data is incorrect.

Thus, examples may enable write checking and write retry without sendingthe data back to the controller to verify if the written data iscorrect. These and other examples described herein nay, in some cases,may improve system reliability, enhance customer experience, and/orreduce service costs.

Referring now to the drawings, FIG. 1 is an example block diagram of adevice 100 to validate that data is written correctly to a memory. Thedevice 100 may interface with or be included in any type of deviceincluding a memory and/or a controller, such as a DRAM, memorycontroller, a notebook computer, a desktop computer, an all-in-onesystem, a server, a network device, a wireless device, a storage device,a mobile device, a thin client, a retail point of sale device, a gamingdevice, a scientific instrument, and the like.

In FIG. 1, the device 100 is shown to include a receiving unit 110, avalidation unit 120 and an alert unit 130. The receiving, validation andalert units 110, 120 and 130 may include, for example, a hardware deviceincluding electronic circuitry for implementing the functionalitydescribed below, such as control logic and/or memory. In addition or asan alternative, the receiving, validation and alert units 110, 120 and130 may be implemented as a series of instructions encoded on amachine-readable storage medium and executable by a processor.

The receiving unit 110 may receive data 104 and a first error detectioncode 102 related to the received data 104. The data 104, for example,may be a packet or datagram sent from a controller or processor (notshown) to be written to a memory (not shown). The term error detectioncode may refer to any coding scheme that allows for detection of errorscaused by noise or other impairments during transmission from atransmitter to a receiver, such as from the controller to a memorydevice or from a memory interface to a storage element within the memorydevice. The error detection code may be realized using a suitable hashfunction or checksum algorithm.

For example, a hash function at the controller sending the data 104 mayadd a fixed-length tag to the data 104, such as the first errordetection code 102, which enables a receiver, such as the device 100, toverify the received data 104 by recomputing the tag and comparing itwith the one provided. There may exist a vast variety of different hashfunction designs. Example types of error detection code may includerepetition code, parity bit, checksum, cyclic redundancy check (CRC),cryptographic hash function, and the like/

The validation unit 120 may validate that the received data 104 iswritten correctly to the memory, based on at least one of the firsterror detection code 102 and a comparison of the written data 104′ tothe received data 104. The validation unit 120 will be explained ingreater detail below with respect to FIGS. 2 and 3. The alert unit 130may generate an alert 132 if the validation unit 120 determines that thewritten data 104′ is incorrect.

FIG. 2 is another example block diagram of a device 200 to validate thatdata 104 is written correctly to a memory 250. The device 200 mayinterface with or be included in any type of device including a memoryand/or a controller, such as a DRAM, memory controller, a notebookcomputer, a desktop computer, an all-in-one system, a server, a networkdevice, a wireless device, a storage device, a mobile device, a thinclient, a retail point of sale device, a gaming device, a scientificinstrument, and the like.

Here, the device 200 is shown to include a memory 250 and interface witha controller 230. While FIG. 2 shows the device 200 to be integratedwith the memory 250, examples may also include the device 200 beingseparate from the memory 250. Example types of the memory 250 may beRandom Access Memory (RAM) like synchronous dynamic random-access memory(SDRAM), dynamic random access memory (DRAM), or graphics RAM. Furtherexample types of the memory 250 may include NAND flash memory and mainmemory.

The controller 230 may include, for example, a hardware device includingelectronic circuitry for implementing the functionality described below,such as control logic and/or memory. In addition or as an alternative,the controller 230 may be implemented as a series of instructionsencoded on a machine-readable storage medium and executable by aprocessor. The controller 230 may be a memory controller or any othertype of device that manages a flow of data going to and from one or morememories, like the memory 250. The controller 230 may also manage theflow of data going to and from a processor or cache (not shown).

The device 200 of FIG. 2 may include the functionality and/or hardwareof the device 100 of FIG. 1. For example, the device 200 includes thealert unit 130. Further, the receiving unit 210 and a validation unit220 included in the device 200 of FIG. 2 may include at least thefunctionality and/or hardware of the receiving unit 110 and thevalidation unit 120 of device 100 of FIG. 1.

The controller 230 may receive the data 104, such as from a processor,and generate the first error detection code 102 based on the data 104.Next, the controller 230 may send the data 104 and the first errordetection code 102 to the receiving unit 220 of the device 200.

In FIG. 2, the receiving unit 210 is shown to have a double data rate(DDR) interface 212. The DDR interface 212 may allow the controller 230and/or the device 200 to transfer data on both rising and falling edgesof a clock signal along a bus. The DDR interface 212 may include anygeneration of DDR, such as DDR first generation (DDR1) through DDRfourth generation (DDR4). Afterward, the data 104′ is written to thememory 250, such as to a storage element (not shown) of an array ofstorage elements (not shown) of the memory 250.

Then, the validation unit 220 may generate a second error detection code222 based on the written data 104′. For example, assuming the firsterror detection code 102 is a CRC, the validation unit 220 may read thewritten data 104′ from memory and calculate its CRC to generate thesecond error detection code 222. Next, the validation unit 220 mayvalidate the written data 104′ as correct if the second error detectioncode 222 matches the first error detection code 102. On the other hand,the validation unit 220 may invalidate the written data 104′ asincorrect if the second error detection code 222 does not match thefirst error detection code 102.

As noted above, the validation unit 220 may signal the written data 104′is incorrect to the alert unit 130. In turn, the alert unit 130 maygenerate an alert 132. The controller 230 may receive the alert 312 andretransmit the data 104 to the receiving unit 210 in response to thealert 132. Thus, examples may close a data reliability hole, byverifying that data 104′ is written correctly to the memory 250 withoutrequiring the data 104′ to be sent back to the controller 230 forvalidation.

FIG. 3 is yet another example block diagram of a device 300 to validatethat data 104 is written correctly to a memory 250. The device 300 mayinterface with or be included in any type of device including a memoryand/or a controller, such as a DRAM, memory controller, a notebookcomputer, a desktop computer, an all-in-one system, a server, a networkdevice, a wireless device, a storage device, a mobile device, a thinclient, a retail point of sale device, a gaming device, a scientificinstrument, and the like.

Here, the device 300 is shown to include the memory 250 and interfacewith the controller 230 of FIG. 2. While FIG. 3 shows the device 300 tobe integrated with the memory 250, examples may also include the device300 being separate from the memory 250. The device 300 of FIG. 2 mayinclude the functionality and/or hardware of the device 100 of FIG. 1and/or the device 200 of FIG. 2. For example, the device 300 includesthe alert unit 130 of FIG. 1 and the receiving unit 210 of FIG. 2.Further, a validation unit 320 included in the device 300 of FIG. 3 mayinclude at least the functionality and/or hardware of the validationunit 120 of device 100 of FIG. 1.

As noted above, the validation unit 320 may receive the data 104 and thefirst error detection code 102 from the controller 230. The validationunit 320 may validate if the received data 104 is correct before thereceived data 104 is written to the memory 250 based on the first errordetection code 102. For example, the validation unit 320 may generate asecond error detection code 322 based 322 on the received data 104,before the received data 104 is written to the memory 250. For instance,the validation unit 320 may run a coding scheme on the received data 104to generate the second error detection code 32, such as a CRC.

Then, the validation unit 320 may compare the second error detectioncode 322 to the first error detection code 102, to determine if thereceived data 104 is correct. The validation unit 320 may invalidate thereceived data 104 as incorrect if the second error detection code 322does not match the first error detection code 102. The received data 104may not be written to the memory 250 if the received data 104 isincorrect. Further, the validation unit 320 may cause the alert unit 130to generate the alert if the received data 104′ is incorrect. On theother hand, the validation unit 320 may validate the received data 104as correct if the second error detection code 322 matches the firsterror detection code 102. The received data 104 may be written to thememory 250 if the received data 104 is correct.

In one example, after the data 104′ is written to memory 250, thevalidation unit 320 may read the written data 104′ from the memory andgenerate a third error detection code 324 based on the written data 104.The validation unit 320 may then compare the third error detection code324 to the first error detection code 102 to validate the written data104′. The validation unit 320 may invalidate the received data 104 asincorrect if the third error detection code 324 does not match the firsterror detection code 102. As noted above, the validation unit 320 maycause the alert unit 130 to generate the alert if the written data 104′is incorrect.

On the other hand, the validation unit 320 may validate the receiveddata 104 as correct if the third error detection code 324 matches thefirst error detection code 102. Thus, the data 104 may be validated bothwhen it is received and after it is written to the memory 250, based oncalculating error detection codes 322 and 324 before and after storingthe data 104, and comparing the calculated error detection codes 322 and324 to the received first error detection code 102.

In another example, the validation unit 320 may not calculate the thirderror detection code 324 to verify if the written data 104′ is correct.Instead, the validation unit 320 may compare the received data 104 tothe written data 104′. The validation unit 320 may validate the writtendata 104′ as correct, if the written data 104′ matches the received data104. The validation unit 320 may invalidate the written data 104′ asincorrect if the written data 104′ does not match the received data 104.Thus, similar to the above example, the data 104 may also be validatedhere both when it is received and after it is written to the memory 250.However, in this example, the written data 104′ may be validated basedon a comparison to the received data 104, not the third error detectioncode 324.

FIG. 4 is an example block diagram of a computing device 400 includinginstructions for validating that data written to a memory is correct. Inthe embodiment of FIG. 4, the computing device 400 includes a processor410 and a machine-readable storage medium 420. The machine-readablestorage medium 420 further includes instructions 422, 424, 426 and 428for validating that data written to a memory (not shown) is correct.

The computing device 400 may be, for example, a secure microprocessor, anotebook computer, a desktop computer, an all-in-one system, a server, anetwork device, a controller, a wireless device, or any other type ofdevice capable of executing the instructions 422, 424, 426 and 428. Incertain examples, the computing device 400 may include or be connectedto additional components such as memories, controllers, etc.

The processor 410 may be, at least one central processing unit (CPU), atleast one semiconductor-based microprocessor, at least one graphicsprocessing unit (GPU), a microcontroller, special purpose logic hardwarecontrolled by microcode or other hardware devices suitable for retrievaland execution of instructions stored in the machine-readable storagemedium 420, or combinations thereof. The processor 410 may fetch,decode, and execute instructions 422, 424, 426 and 428 to implementvalidating that data written to the memory is correct. As an alternativeor in addition to retrieving and executing instructions, the processor410 may include at least one integrated circuit (IC), other controllogic, other electronic circuits, or combinations thereof that include anumber of electronic components for performing the functionality ofinstructions 422, 424, 426 and 428.

The machine-readable storage medium 420 may be any electronic, magnetic,optical, or other physical storage device that contains or storesexecutable instructions. Thus, the machine-readable storage medium 420may be, for example, Random Access Memory (RAM), an ElectricallyErasable Programmable Read-Only Memory (EEPROM), a storage drive, aCompact Disc Read Only Memory (CD-ROM), and the like. As such, themachine-readable storage medium 420 can be non-transitory. As describedin detail below, machine-readable storage medium 420 may be encoded witha series of executable instructions for validating that data written tothe memory is correct.

Moreover, the instructions 422, 424, 426 and 428 when executed by aprocessor (e.g., via one processing element or multiple processingelements of the processor) can cause the processor to perform processes,such as, the process of FIG. 5. For example, the receive instructions422 may be executed by the processor 410 to receive a first errordetection code related to the data to be written to the memory. Thewrite instructions 424 may be executed by the processor 410 to write thereceived data to the memory. The validate instructions 426 may beexecuted by the processor 410 to validate that the data written to thememory is correct based on at least one the first error detection codeand a comparison of the written data to the received data.

For example, instructions may be executed by the processor 410 togenerate a second error detection code based on the written data. Thesecond error detection code may be compared to the first error detectioncode to validate if the written data is correct for the validateinstructions 426. Optionally, additional instructions may be executed bythe processor 410 to generate a third error detection code based on thereceived data. In this case, the validate instructions 426 may beexecuted by the processor 410 to validate that the received data iscorrect based on a comparison of the first error detection code to thethird error detection code, before the received data is written to thememory. Thus, the data may be validated both when it is received andafter it is written to the memory.

In another example, the additional instructions may still be executed bythe processor 410 to generate the third error detection code, asexplained above. However, instead of generating the second errordetection code, the written data may be compared to the received memoryto validate if the written data is correct for the validate instructions426. Thus, similar to the above example, the data may also be validatedhere both when it is received and after it is written to the memory.However, in this example, the data may be validated after is to writtento the memory based on a comparison to the received data, not the seconderror detection code.

The generate instructions 428 may be executed by the processor 410 togenerate an error if the written data is incorrect. The error is to besent to a controller (not shown) that sent the data to the memory. Thus,the written data may be validated without sending the data back to thecontroller.

FIG. 5 is an example flowchart of a method 500 for validating that datawritten to a memory is correct. Although execution of the method 500 isdescribed below with reference to the device 200, other suitablecomponents for execution of the method 500 can be utilized, such as thedevice 100. Additionally, the components for executing the method 500may be spread among multiple devices (e.g., a processing device incommunication with input and output devices). In certain scenarios,multiple devices acting in coordination can be considered a singledevice to perform the method 500. The method 500 may be implemented inthe form of executable instructions stored on a machine-readable storagemedium, such as storage medium 420, and/or in the form of electroniccircuitry.

At block 510, the device 200 receives data 104 to be written to a memory250 and a first error detection code 102 related to the data 104. Then,at block 520, the device 200 writes the data 104′ to the memory 250.Next, at block 530, the device 200 generates a second error detectioncode 222 based on the written data 104′. Afterward, at block 540, thedevice 200 compares the second error detection code 222 to the firsterror detection code 102 to validate that the written data 104′ iscorrect, Lastly, at block 550, the device 200 generates an alert 132, ifthe first error detection code 102 does not match the second errordetection code 222.

FIG. 6 is another example flowchart of a method for validating that datawritten to a memory is correct, Although execution of the method 600 isdescribed below with reference to the device 300, other suitablecomponents for execution of the method 600 can be utilized, such as thedevice 100. Additionally, the components for executing the method 600may be spread among multiple devices (e.g., a processing device incommunication with input and output devices). In certain scenarios,multiple devices acting in coordination can be considered a singledevice to perform the method 600. The method 600 may be implemented inthe form of executable instructions stored on a machine-readable storagemedium, such as storage medium 420, and/or in the form of electroniccircuitry.

At block 610, the device 300 receives data 104 to be written to a memory250 and a first error detection code 102 related to the data 104. Then,at block 620, the device 300 generates a second error detection code 322based on the received data 104, Next, at block 630, the device comparesthe second error detection code 322 to the first error detection code102. If the second error detection code 322 does not match the firsterror detection code 102, the method 600 flows to block 640, where thedevice 300 generates an alert, Otherwise, if the second error detectioncode 322 does match the first error detection code 102, the method 600flows to block 650, where the device 300 write the data 104 to thememory 250.

Next, at block 660, the device 300 generates a third error detectioncode 324 based on the written data 104′. Afterward, at block 670, thedevice 300 compares the third error detection code 324 to the firsterror detection code 102 to validate that the written data 104′ iscorrect. If the third error detection code 324 does not match the firsterror detection code 102, the method 600 flows back to block 640, wherethe device 300 generates the alert. Otherwise, if the third errordetection code 324 does match the first error detection code 102, themethod 600 flows back to the beginning at block 610.

We claim:
 1. A device, comprising: a receiving unit to receive data anda first error detection code related to the received data; a validationlit to validate that the received data is written correctly to a memory,based on at least one of the first error detection code and a comparisonof the written data to the received data; and an alert unit to generatean alert if the validation unit determines that the written data isincorrect.
 2. The device of claim 1, wherein the validation unit is tofurther validate if the received data is correct before the receiveddata is written to the memory based on the first error detection code.3. The device of claim 2, wherein, the validation unit is to generate asecond error detection code based on the received data, before thereceived data is written to the memory, and the validation unit is tocompare the second error detection code to the first error detectioncode, to determine if the received data is correct.
 4. The device ofclaim 3, wherein, the validation unit is to invalidate the received dataas incorrect if the second error detection code does not match the firsterror detection code, and the validation unit is to validate thereceived data as correct if the second error detection code matches thefirst error detection code.
 5. The device of claim 4, wherein, thevalidation unit is to compare the received data to the written data, ifthe received data is validated as correct, the validation unit isvalidate the written data as correct, if the written data matches thereceived data, and the validation unit is to invalidate the written dataas incorrect if the written data does not match the received data. 6.The device of claim 4, wherein, the received data is written to thememory if the received data is correct, and the received data is notwritten to the memory if the received data is incorrect.
 7. The deviceof claim 1, wherein, the validation unit is generate a second errordetection code based on the written data, and the validation unit is tovalidate the written data as correct if the second error detection codematches the first error detection code, and the validation unit is toinvalidate the written data as incorrect if the second error detectioncode does not match the first error detection code.
 8. The device ofclaim 1, wherein, a controller generates the first error detection codebefore sending the data to the receiving unit, and the controller is toreceive the alert and to retransmit the data to the receiving unit inresponse to the alert.
 9. The device of claim 1, wherein, the receivingunit receives the data via a double data rate (DDR) memory interface,the error detection code is a cyclic redundancy check (CRC), and thememory is a dynamic random-access memory (DRAM).
 10. A method,comprising: receiving data to be written to a memory and a firstdetection code related to the data; writing the data to the memory;generating a second error detection code based on the written data;comparing the second error detection code to the first error detectioncode to validate that the written data is correct; and generating analert, if the first error detection code does not match the second errordetection code.
 11. The method of claim 10, further comprising:generating a third error detection code based on the received data,before the writing; comparing the third error detection code to thefirst error detection code; and generating the alert, if the first errordetection de does not match third detection code.
 12. A non-transitorycomputer-readable storage medium storing instructions that, if executedby a processor of a device, cause the processor to: receive a firsterror detection code related to data to be written to a memory; writethe received data to the memory; validate that the data written to thememory is correct based on at least one the first error detection codeand a comparison of the written data to the received data; and generatean error if the written data is incorrect, the error to be sent to acontroller that sent the data to the memory, wherein the written data isvalidated without sending the received data back to the controller. 13.The non-transitory computer-readable storage medium of claim 12, furthercomprising instructions that, if executed by a processor of a device,cause the processor to: generate a second error detection code based onthe written data, wherein the second error detection code is compared tothe first error detection code to validate if the written data iscorrect.
 14. The non-transitory computer-readable storage medium ofclaim 13, further comprising instructions that, if executed by aprocessor of a device, cause the processor to: generate a third errordetection code based on the received data; and validate the receiveddata is correct based on a comparison of the first error detection codeto the third error detection code, before the received data is writtento the memory.
 15. The non-transitory computer-readable storage mediumof claim 12, further comprising instructions that, if executed by aprocessor of a device, cause the processor to: generate a second errordetection code based on the received data; validate the received data iscorrect based on a comparison of the first error detection code to thesecond error detection code, before the received data is written to thememory; and compare the written memory to received memory code tovalidate if the written data is correct.